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Foreword 

This Technical Specification has been produced by the 3GPP. 

The contents of the present document are subject to continuing work within the TSG and may 
change following formal TSG approval. Should the TSG modify the contents of this TS, it will be 
re-released by the TSG with an identifying change of release date and an increase in version number 
as follows: 

Version 3.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, 

corrections, updates, etc. 
z the third digit is incremented when editorial only changes have been incorporated in the 

specification; 
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1 Scope 

The present document is a technical specification of the services provided by the physical layer of 
UTRA to upper layers. 



2 References 

References may be made to: 

a) specific versions of publications (identified by date of publication, edition number, version 
number, etc.), in which case, subsequent revisions to the referenced document do not apply; 

b) all versions up to and including the identified version (identified by "up to and including" 
before the version identity); 

c) all versions subsequent to and including the identified version (identified by "onwards" 
following the version identity); or 

d) publications without mention of a specific version, in which case the latest version applies. 
A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN 
with the same number. 

[1] ETSI UMTS 23.10 : UMTS Access Stratum Services and Functions 

[2] 3 GPP RAN S2.01 : Radio Interface Protocol Architecture 

[3] ETSI UMTS XX.04 UTRA FDD multiplexing, channel coding and interleaving 

description 

[4] ETSI UMTS XX. 10 UTRA TDD multiplexing, channel coding and interleaving 

description 
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3 Definitions and Abbreviations 

3.1 Definitions 

See [3] for a definition of fundamental concepts and vocabulary. 

3.2 Abbreviations 



ARQ 


Automatic Repeat Request 


BCCH 


Broadcast Control Channel 


BCH 


Broadcast Channel 


C- 


Control- 


CC 


Call Control 


CCCH 


Common Control Channel 


CCH 


Control Channel 


CCTrCH 


Coded Composite Transport Channel 


CN 


Core Network 


CRC 


Cyclic Redundancy Check 


DC 


Dedicated Control (SAP) 


DCA 


Dynamic Channel Allocation 


DCCH 


Dedicated Control Channel 


DCH 


Dedicated Channel 


DL 


Downlink 


DRNC 


Drift Radio Network Controller 


DSCH 


Downlink Shared Channel 


DTCH 


Dedicated Traffic Channel 


FACH 


Forward Link Access Channel 


FAUSCH 


Fast Uplink Signalling Channel 


FCS 


Frame Check Sequence 


FDD 


Frequency Division Duplex 


GC 


General Control (SAP) 


HO 


Handover 


ITU 


International Telecommunication Union 


kbps 


kilo-bits per second 


LI 


Layer 1 (physical layer) 


L2 


Layer 2 (data link layer) 


L3 


Layer 3 (network layer) 


LAC 


Link Access Control 


LAI 


Location Area Identity 


MAC 


Medium Access Control 


MM 


Mobility Management 


Nt 


Notification (SAP) 


OCCCH 


ODMA Common Control Channel 


ODCCH 


ODMA Dedicated Control Channel 


ODCH 


ODMA Dedicated Channel 


ODMA 


Opportunity Driven Multiple Access 


ORACH 


ODMA Random Access Channel 


ODTCH 


ODMA Dedicated Traffic Channel 


PCCH 


Paging Control Channel 
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PCH Paging Channel 

PDU Protocol Data Unit 

PHY Physical layer 

PhyCH Physical Channels 

RACH Random Access Channel 

RLC Radio Link Control 

RNC Radio Network Controller 

RNS Radio Network Subsystem 

RNTI Radio Network Temporary Identity 

RRC Radio Resource Control 

SAP Service Access Point 

SCCH Synchronization Control Channel 

SCH Synchronization Channel 

SDU Service Data Unit 

SRNC Serving Radio Network Controller 

SRNS Serving Radio Network Subsystem 

TCH Traffic Channel 

TDD Time Division Duplex 

TFCI Transport Format Combination Indicator 

TFI Transport Format Indicator 

TMSI Temporary Mobile Subscriber Identity 

TPC Transmit Power Control 

U- User- 

UE User Equipment 

UEr User Equipment with ODMA relay operation enabled 
UL Uplink 

UMTS Universal Mobile Telecommunications System 

URA UTRAN Registration Area 
UTRA UMTS Terrestrial Radio Access 

UTRAN UMTS Terrestrial Radio Access Network 
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4 Interfaces to the physical layer 

The physical layer (layer 1) is the lowest layer in the OSI Reference Model and it supports all 
functions required for the transmission of bit streams on the physical medium. 
The physical layer interfaces the Medium Access Control (MAC) Layer and the Radio Resource 
Control (RRC) Layer as depicted in figure 2.1 . 



Layer 3 



Radio Resource Control (RRC) 

o 



Layer 2 



Layer 1 



Medium Access Control 



CPHY primitives 



PHY primitives 



Physical Layer 



Figure 1 : Interfaces with the Physical Layer 

4.1 Interface to MAC 

The physical layer interfaces the MAC entity of layer 2.. Communication between the Physical 
Layer and MAC is in an abstract way performed by means of PH-primitives defined which do not 
constrain implementations. 

NOTE: The terms physical layer and layer 1, will be used synonymously in this description. 
The PH-primitives exchanged between the physical layer and the data link layer provide the 
following functions: 

• transfer of transport blocks over the radio interface 

• indicate the status of the layer 1 to layer 2 



4.2 Interface to RRC 

The physical layer interfaces the RRC entity of layer 3 in the UE and in the network. 

Communication is performed in an abstract way by means of MPH-primitives. They do not 
constrain implementations. 

The MPH-primitives exchanged between the physical layer and the Network layer provide the 
following function: 

• control of the configuration of the physical layer 
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The currently identified exchange of information across that interface have only a local significance 
to the UE or Network. 
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5 Services and functions of the physical layer 

5.1 General 

The physical layer offers data transport services to higher layers. The access to these services is 
through the use of transport channels via the MAC sub-layer. The characteristics of a transport 
channel are defined by its transport format (or format set), specifying the physical layer processing 
to be applied to the transport channel in question, such as outer coding and interleaving (if any), and 
inner channel coding and interleaving, and any service-specific rate matching as needed. 

The physical layer operates exactly according to the LI radio frame timing. A transport block is 
defined as the data accepted by the physical layer to be jointly encoded. The transmission block 
timing is then tied exactly to this LI frame timing, e.g. every transmission block is generated 
precisely every 10ms, or a multiple of 10 ms. 

A UE can set up multiple transport channels simultaneously, each having own transport 
characteristics (e.g. offering different error correction capability). Each transport channel can be 
used for information stream transfer of one radio bearer or for layer 2 and higher layer signalling 
messages. 

The multiplexing of these transport channels onto the same or different physical channels is carried 
out by LI. In addition, the Transport Format Combination Indication field (TFCI) shall uniquely 
identify the transport format used by each transport channel of the Coded Composite Transport 
Channel within the current radio frame. 

5.2 Overview of L1 functions 

The physical layer performs the following main functions: 

• FEC encoding/decoding of transport channels 

• Measurements and indication to higher layers (e.g. FER, SIR, interference power, transmission 
power, etc.) 

• Macrodiversity distribution/combining and soft handover execution 

• Error detection on transport channels 

• Multiplexing of transport channels and demultiplexing of coded composite transport channels 

• Rate matching 

• Mapping of coded composite transport channels on physical channels 

• Modulation and spreading/demodulation and despreading of physical channels 

• Frequency and time (chip, bit, slot, frame) synchronization 

• Closed-loop power control 

• Power weighting and combining of physical channels 

• RF processing 
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5.3 L1 interactions with L2 retransmission functionality 

Provided that the RLC PDUs are mapped one-to-one onto the Transport Blocks, Error indication 
may be provided by LI to L2. For that purpose, the LI CRC can be used for individual error 
indication of each RLC PDU. The LI CRC will then serve multiple purposes: 

• Error indication for uplink macro diversity selection combining (LI) 

• Frame error indication for speech services 

• Quality indication 

• Error indication for L2 retransmissions 

For Transport Channels using outer coding (RS-coding) information from the RS-decoder may be 
used for error indication for the purpose of L2 re-transmissions. 

As a conclusion, LI needs to give an error indication to L2 for each erroneous Transport Block 
delivered. 
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6 Model of physical layer of the UE 
6.1 Uplink models 

Figure 2 shows models of the UE's physical layer in the uplink for both FDD and TDD mode. It 
shows two models: DCH model and RACH model. Only one type of transport channel is used at a 
time by one UE. Hence, both models are not in use simultaneously within one UE. More details can 
be found in [3] and [4]. 

Editors note: Models for uplink transport channels currently marked ffs will be necessary if these 
channels are included in the description. 



DCH model 

DCH DCH DCH 
J I 



FAUSCH model 
FAUSCH 



Coding and 
multiplexing 



Coded Composite 
Transport Channel 
(CCTrCH) 



Demultiplexing/ 



j splitting 
Physical Channel! 

Data Streams w 



Transport 

Format Combination 
Indicator 
(TFCI) 



V 



V 



FDD only 



TPC^PfefflL 



BSC 



RACH model 
RACH 

Coding 



Figure 2: Model of the UE's physical layer - uplink 

The DCH model shows that one or several DCHs can be processed and multiplexed together by the 
same coding and multiplexing unit. The detailed functions of the coding and multiplexing unit are 
not defined in this document but in XX.04 [1] and XX. 10 [2]. The single output data stream from 
the coding and multiplexing unit is denoted Coded Composite Transport Channel (CCTrCH). 

The data stream of the CCTrCH is fed to a data demultiplexing/splitting unit that 
demultiplexes/splits the CCTrCH's data stream onto one or several Physical Channel Data Streams. 

Editors 's note: The term "splitting" used for above function in FDD mode has been replaced by 
"demultiplexing/splitting". The intention of using the term splitting is to express that this function is 
performed on bit level not on some block level. The term demultiplexing/splitting shall cover both 
cases, block or bit level demultiplexing, where block lengths larger than 1 bit may be applied in the 
TDD mode. This needs to be confirmed by the LI group 

The current configuration of the coding and multiplexing unit is either signalled to, or optionally 
blindly detected by, the network for each 10 ms frame. If the configuration is signalled, it is 
represented by the Transport Format Combination Indicator (TFCI) bits. Note that the TFCI 
signalling only consists of pointing out the current transport format combination within the already 
configured transport format combination set. In the uplink there is only one TFCI representing the 
current transport formats on all DCHs of one CCTrCH simultaneously. In FDD mode, the physical 
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channel data stream carrying the TFCI is mapped onto the physical channel carrying the power 
control bits and the pilot. 

For the FAUSCH, there is no coding, since the FAUSCH is only used for the transmission of a 
reservation request by sending an up-link signalling code (USC) at the time-offset allocated for the 
specific UE during the 10 ms frame. Due to the fixed time-offset allotted to a specific UE, the 
FAUSCH is a dedicated control channel. 

The model for the RACH case shows that RACH is the only common type transport channel in the 
uplink. RACHs are always mapped one-to-one onto physical channels, i.e. there is no physical layer 
multiplexing of RACH. Service multiplexing is handled by the MAC layer. 

6.2 Downlink models 

Figure 3 and Figure 4 show the model of the UE's physical layer for the downlink in FDD and TDD 
mode, respectively. Note that there is a different model for each transport channel type. 

Editors note: Models for downlink transport channels currently marked ffs will be necessary if these 
channels are included in the description. 
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Figure 3: Model of the UE's physical layer - downlink FDD mode 
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Figure 4: Model of the UE's physical layer - downlink TDD mode 



For the DCH case, the mapping between DCHs and physical channel data streams works in the 
same way as for the uplink. Note however, that the number of DCHs, the coding and multiplexing 
etc. may be different in uplink and downlink. 

In the FDD mode, the differences are mainly due to the soft and softer handover. Further, the pilot, 
TPC bits and TFCI are time multiplexed onto the same physical channel(s) as the DCHs. Further, 
the definition of physical channel data stream is somewhat different from the uplink. 

Note that it is logically one and the same physical data stream in the active set of cells, even though 
physically there is one stream for each cell. The same processing and multiplexing is done in each 
cell. The only difference between the cells is the actual codes, and these codes correspond to the 
same spreading factor. 

The physical channels carrying the same physical channel data stream are combined in the UE 
receiver, excluding the pilot, and in some cases the TPC bits. TPC bits received on certain physical 
channels may be combined provided that UTRAN has informed the UE that the TPC information on 
these channels is identical. 

The downlink models for the BCH, PCH and FACH show that BCH, PCH and FACH are always 
mapped one-to-one onto physical channels, i.e. there is no physical layer multiplexing of BCH, PCH 
and FACH. Service multiplexing is handled by the MAC layer. Note, in the TDD mode there is the 
SCH in addition (not shown in Figure 4). 

6.3 Relay link Model 

The Relay link applies to the TDD mode only. The applicability to the FDD mode is FFS. 
Figure 4 illustrates the model of the UE's physical layer for the TDD mode. 
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ODCH model 

ODCH 
A 



ORACHmodel 
ORACH 



Coding 



A 




Figure 5 : Model of the UE's physical layer - relay link TDD mode. 

The ORACH is a channel used within UE's to transmit and receive probing messages, and also to 
transmit and receive small packets of information. The ODCH is used to transmit larger amounts of 
data over a number of hops between UE's. 



7 Formats and configurations for L1 data transfer 
7.1 General concepts about Transport Channels 

Layer 2 is responsible for the mapping of data onto LI via the L1/L2 interface that is formed by the 
transport channels. In order to describe how the mapping is performed and how it is controlled, 
some definitions and terms are required. The required definitions are given in the following 
sections. Note that the definitions are generic for all transport channel types, i.e. not only for DCHs. 

All Transport Channels are defined as unidirectional (i.e. uplink, downlink, or relay-link). This 
means that a UE can have simultaneously (depending on the services and the state of the UE) one or 
several transport channels in the downlink, and one or more Transport Channel in the uplink. 

7.1.1 Transport Block 

This is the basic unit exchanged between LI and MAC, for LI processing. 

A Transport Block typically corresponds to an RLC PDU or corresponding unit. In the TDD mode it 
may possibly also be formed by a MAC peer-to-peer message. Layer 1 adds a CRC for each 
Transport Block. 

Transport Block Set This is defined as a set of Transport Blocks which are exchanged between LI 
and MAC at the same time instance using the same transport channel. 

7.1 .2 Transport Block Size 

This is defined as the number of bits in a Transport Block. 



7.1 .3 Transport Block Set Size 

This is defined as the number of bits in a Transport Block Set. 
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7.1.4 Transmission Time Interval 

This is defined as the inter-arrival time of Transport Block Sets, i.e. the periodicity at which a 
Transport Block Set is transferred by the physical layer. It is always a multiple of the minimum 
interleaving period (e.g. 10ms, the length of one Radio Frame). 

Figure 6 shows an example where Transport Block Sets, at certain time instances, are exchanged 
between MAC and LI via three parallel transport channels. Each Transport Block Set consists of a 
number of Transport Blocks. The Transmission Time Interval, i.e. the time between consecutive 
deliveries of data between MAC and LI, is also illustrated. Last, the case when the last Transport 
Block is smaller than the allowed size is shown, with the topmost Transport Block being partially 
empty. 

DCHl 
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Transport 
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"Transmission Time Interval 
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I Transport 



I Transport 



I Transport 
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I Transport 
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[Transport 
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Figure 6. Exchange of data between MAC and LI 



7.1.5 Transport Format 

This is defined as a format offered by LI to MAC (and vice versa) for the delivery of a Transport 
Block Set during a Transmission Time Interval on a Transport Channel. The Transport Format 
constitutes of two parts - one dynamic part and one semi-static part. 

Attributes of the dynamic part are: 

• Transport Block Size 

• Transport Block Set Size 

• Transmission Time Interval (option for TDD only) 
Attributes of the semi-static part are: 

• Transmission Time Interval (mandatory for FDD, optional for the dynamic part of TDD NRT 
bearers) 
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• Type of channel coding 

• Outer coding (e.g. Reed-Solomon) 

• Outer interleaving (depth of the outer interleaving in radio frames) 

• Inner coding 

• Inner interleaving (depth of the inner interleaving in radio frames) 

• Rate matching 

In the following example, the Transmission time Interval is seen as a semi-static part 
Example: 

• Dynamic part: {320 bits, 640 bits}, Semi-static part: {10ms, Inner coding only, repeat 1/12 of the 
bits} 

7.1.6 Transport Format Set 

This is defined as the set of Transport Formats associated to a Transport Channel. 

The semi-static parts of all Transport Formats are the same within a Transport Format Set. 

Effectively the first two attributes of the dynamic part form the instantaneous bit rate on the 
Transport Channel. Variable bit rate on a Transport Channel may, depending on the type of service 
which is mapped onto the transport channel, be achieved by changing between each Transmission 
Time Interval one of the following: 

1. the Transport Block Size only 

2. the Transport Block Set Size only 

3. both the Transport Block Size and the Transport Block Set Size 
Example 1: 

• Dynamic part: {20 bits, 20 bits}; {40 bits, 40 bits}; {80 bits, 80 bits}; {160 bits, 160 bits} 

• Semi-static part: {10ms, Inner coding only, repeat 1/12 of the bits} 

Example 2: 

• Dynamic part: {320 bits, 320 bits}; {320 bits, 640 bits}; {320 bits, 1280 bits} 

• Semi-static part: { 1 0ms, Inner coding only, repeat 1/12 of the bits} 

The first example may correspond to a Transport Channel carrying a speech service, requiring 
blocks delivered on a constant time basis. In the second example, which illustrates the situation 
where a non-real time service is carried by the Transport Channel, the number of blocks delivered 
per Transmission Time Interval varies between the different Transport Formats within the Transport 
Format Set. Referring to Figure 6, the Transport Block Size is varied on DCH1 whereas the 
Transport Block Set Size is fix. That is, a Transport Format Set where the dynamic part has a 
variable Transport Block Size has been assigned for DCH1. On DCH2 and DCH3 it is instead the 
Transport Block Set Sizes that are varied. That is, the dynamic parts of the corresponding Transport 
Format Sets include variable Transport Block Set Sizes. 

7.1.7 Transport Format Combination 

The layer 1 multiplexes one or several Transport Channels, and for each Transport Channel, there 
exists a list of transport formats (Transport Format Set) which are applicable. Nevertheless, at a 
given point of time, not all combinations may be submitted to layer 1 but only a subset, the 
Transport Format Combination. This is defined as an authorised combination of the combination of 
currently valid Transport Formats that can be submitted simultaneously to the layer 1 for 
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transmission on a Coded Composite Transport Channel of a UE, i.e. containing one Transport 
Format from each Transport Channel. 

Example: 

DCH1: Dynamic part: {20 bits, 20 bits}, Semi-static part: {10ms, Inner coding only, repeat 1/12 of 
the bits} 

DCH2: Dynamic part: {320 bits, 1280 bits}, Semi-static part: {10ms, Inner coding only, puncture 
1/14 of the bits} 

DCH3: Dynamic part: {320 bits, 320 bits}, Semi-static part: {40ms, Outer coding, repeat 1/20 of 
the bits} 

7.1.8 Transport Format Combination Set 

This is defined as a set of Transport Format Combinations on a Coded Composite Transport 
Channel. 

Example: 

Dynamic part: 

Combination 1: DCH1: {20 bits, 20 bits}, DCH2: {320 bits, 1280 bits}, DCH3: {320 bits, 320 bits} 
Combination 2: DCH1: {40 bits, 40 bits}, DCH2: {320 bits, 1280 bits}, DCH3: {320 bits, 320 bits} 
Combination 3: DCH1: {160 bits, 160 bits}, DCH2: {320 bits, 320 bits}, DCH3: {320 bits, 320 
bits} 

Semi-static part: 

DCH1: {10ms, Inner coding only, repeat 1/12 of the bits} 
DCH2: {10ms, Inner coding only, puncture 1/14 of the bits} 
DCH3: {40ms, Outer coding, repeat 1/20 of thebits} 

The Transport Format Combination Set is what is given to MAC for control. However, the 
assignment of the Transport Format Combination Set is done by L3. When mapping data onto LI, 
MAC chooses between the different Transport Format Combinations given in the Transport Format 
Combination Set. Since it is only the dynamic part that differ between the Transport format 
Combinations, it is in fact only the dynamic part that MAC has any control over. 

The semi-static part, together with the target value for the LI closed loop power control, correspond 
to the service attributes: 

• Quality (e.g. BER) 

• Transfer delay 

These service attributes are then offered by LI. However, it is L3 that guarantees that the LI 
services are fulfilled since it is in charge of controlling the LI configuration, i.e. the setting of the 
semi-static part of the Transport Formats. Furthermore, L3 controls the target for the LI closed loop 
power control through the outer loop power control (which actually is a quality control rather than a 
power control). 
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Note that a Transport Format Combination Set need not contain all possible Transport Format 
Combinations that can be formed by Transport Format Sets of the corresponding Transport 
Channels. It is only the allowed combinations that are included. Thereby a maximum total bit rate of 
all transport channels of a Code Composite Transport Channel can be set appropriately. That can be 
achieved by only allowing Transport Format Combinations for which the included Transport 
Formats (one for each Transport Channel) do not correspond to high bit rates simultaneously. 

The selection of Transport Format Combinations can be seen as a fast part of the radio resource 
control. The dedication of these fast parts of the radio resource control to MAC, close to LI, means 
that the flexible variable rate scheme provided by LI can be fully utilised. These parts of the radio 
resource control should be distinguished from the slower parts, which are handled by L3. Thereby 
the bit rate can be changed very fast, without any need for L3 signalling. 

7.1.9 Transport Format Indicator (TFI) 

The TFI is a label for a specific transport format within a transport format set. It is used in the inter- 
layer communication between MAC and LI each time a transport block set is exchanged between 
the two layers on a transport channel. 

7.1.10 Transport Format Combination Indicator (TFCI) 

This is a representation of the current Transport Format Combination. 

There is a one-to-one correspondence between a certain value of the TFCI and a certain Transport 
Format Combination. The TFCI is used in order to inform the receiving side of the currently valid 
Transport Format Combination, and hence how to decode, de-multiplex and deliver the received 
data on the appropriate Transport Channels. 

MAC indicates the TFI to Layer 1 at each delivery of Transport Block Sets on each Transport 
Channel. Layer 1 then builds the TFCI from the TFIs of all parallel transport channels of the UE , 
processes the Transport Blocks appropriately and appends the TFCI to the physical control 
signalling . Through the detection of the TFCI the receiving side is able to identify the Transport 
Format Combination. For FDD, in case of limited Transport Format Combination Sets the TFCI 
signalling may be omitted, instead relying on blind detection. Nevertheless, from the assigned 
Transport Format Combinations, the receiving side has all information it needs in order to decode 
the information and transfer it to MAC on the appropriate Transport Channels. 

The multiplexing and exact rate matching patterns follow predefined rules and may therefore be 
derived (given the Transport Format Combinations) by transmitter and receiver without signalling 
over the radio interface. 

When the meaning of the TFCI field needs to be reconfigured, two procedures can be used 
depending on the level of reconfiguration: 

• Complete reconfiguration of TFCI: In this procedure all TFCI values are reinitialized 
and new values are defined instead. The complete reconfiguration requires an explicit 
synchronization between the UE and UTRAN regarding when the reconfiguration 
becomes valid. 

• Incremental reconfiguration of TFCI: In this procedures, a part of the TFCI values 
before and after the reconfiguration remain identical (note that this must be true for at 
least a TFCI that carry the signaling connection). This procedure supports addition, 
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removal or redefinition of TFCI values. This procedure does not require an explicit 
execution time. 

7.2 Types of Transport Channels 

A general classification of transport channels is into two groups: 

• common channels (where there is a need for in-band identification of the UEs when particular 
UEs are addressed) and 

• dedicated channels (where the UEs are identified by the physical channel, i.e. code and 
frequency) 

Common transport channel types are: 

1 . Random Access Channel(s) (RACH) characterized by: 

• existence in uplink only, 

• limited data field. The exact number of allowed bits is FFS. 

• collision risk, 

• open loop power control, 

• requirement for in-band identification of the UEs. 

2. ODMA Random Access Channel(s) (ORACH) characterized by: 

• used in TDD mode only (FDD is for FFS) 

• existence in relay-link 

• collision risk, 

• open loop power control, 

• no timing advance control 

• requirement for in-band identification of the UE. 

3. Forward Access Channel(s) (FACH) characterized by: 

• existence in downlink only, 

• possibility to use beam forming, 

• possibility to use slow power control, 

• possibility to change rate fast (each 10ms), 

• lack of fast power control and 
• 

4. Broadcast Channel (BCH) characterized by: 

• existence in downlink only, 

• low fixed bit rate and 

• requirement to be broadcast in the entire coverage area of the cell. 

5. Paging Channel (PCH) characterized by: 

• existence in downlink only, 
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• possibility for sleep mode procedures and 

• requirement to be broadcast in the entire coverage area of the cell. 

6. Synchronisation channel (SCH) characterised by : 

• existence in TDD and downlink only 

• low fixed bit rate 

• requirement to be broadcast in the entire coverage area of the cell 

7. Downlink Shared Channel(s) (DSCH) characterised by: 

• existence in downlink only, 

• possibility to use beamforming, 

• possibility to use slow power control, 

• possibility to use fast power control, when associated with dedicated channel(s) 

• possibility to be broadcast in the entire cell 

• always associated with another channel (DCH or DSCH Control Channel). 

8. DSCH Control Channel characterised by: 

• existence in downlink only, 

• possibility to use beam forming, 

• possibility to use slow power control, 

• lack of fast power control and 
• 

Editor ' s note: It is for further study whether or not the DSCH Control Channel needs to be 
regarded as separate transport channel type from FACH. Seen from the upper layers, the 
current requirements are identical to a FACH, but some extra LI information (e.g.TPC 
bits) may lead to a different physical channel 

9. Uplink Shared channel (USCH) characterised by: 

• used in TDD only 

• existence in uplink only, 

• possibility to use beam forming, 

• possibility to use power control, 

• possibility to change rate fast 

Dedicated transport channel types are: 

1 . Dedicated Channel (DCH) characterized by: 

• existing in uplink or downlink 

• possibility to use beam forming, 

• possibility to change rate fast (each 10ms), 



3 GPP 



23 



TS 25.302 V2.0.0 (1999-04) 



• fast power control and 

• inherent addressing of UEs. 

2. Fast Uplink Signaling Channel (FAUSCH) to allocate, in conjunction with FACH, dedicated 
channels; the FAUSCH is characterized by: 

• existing in uplink only, 

• inherent addressing of a UE by a unique time-offset (indicating to a UE when to send an 
uplink signalling code, USC) related to the beginning of the 10 ms frame, 

• allowing for a UE to notify (by sending an USC) a request for a DCH, the allocation of 
which is messaged via the FACH. No further information is conveyed via the FAUSCH, 

• applicability for TDD mode is FFS. 

3. ODMA Dedicated Channel (ODCH) characterized by: 

• used in TDD mode only (FDD is for FFS), 

• possibility to use beam forming, 

• possibility to change rate fast (each 1 0ms), 

• closed loop power control, 

• closed loop timing advance control, 

• temporary addressing of UE. 

To each transport channel (except for the FAUSCH, since it only conveys a reservation request),, 
there is an associated Transport Format (for transport channels with a fixed or slow changing rate) 
or an associated Transport Format Set (for transport channels with fast changing rate). 

7.3 Slotted Mode 

Slotted Mode is defined as the mechanism whereby certain idle periods are created in downlink 
radio frames so that the UE can perform measurement reports during these periods (more details can 
be found in [3]). Applicability to uplink is FFS. 

Slotted Mode is obtained by layer 2 using transport channels provided by the layer 1 as follows : 

• Slotted Mode is controlled by the RRC layer which configures the layer 2 and the physical layer 

• The number of occurrences of slotted frames is controlled by RRC, and can be modified by RRC 
signalling 

• Layer 2 instructs every Transmission Time Interval the Layer 1 on whether slotted mode should 
be applied for a given Transport Format Combination Set. The instruction may indicate also the 
type of slotted mode (beginning, middle or end of the frame). 

• The slotting can be either cyclic (typically for circuit services) or a-periodic (typically for NRT 
services) 

• It is under the responsibility of the layer 2 if necessary to either buffer some layer 2 PDUs 
(typically at the RLC layer for NRT services) or to rate adapt the data flow (similarly to GSM) so 
that there is no loss of data because of slotted mode. This will be service dependant and 
controlled by the RRC layer. 
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8 Primitives of the physical layer 

The Physical layer interacts with other entities as illustrated in figure 2.1. The interactions with the 
MAC layer and the RRC layer are shown in terms of primitives where the primitives represent the 
logical exchange of information and control between the physical layer and higher layers. They do 
not specify or constrain implementations. For the physical layer two sets of primitives are defined: 

* Primitives between layer 1 and 2: 
PHY - Generic name - Type: Parameters. 

* Primitives between layer 1 and the RRC entity: 
CPHY - Generic name - Type: Parameters. 

8.1 Generic names of primitives between layers 1 and 2 

Editor's note : the following list of primitives contains the first part of the generic primitives 
between the physical layer and upper layers. It is not complete yet Further primitives will be 
incorporated when the modelling of the physical layer is further refined. In particular, most of the 
parameters to the primitives are FFS. 

8.1.1 PHY-CONNECT 

Note: This primitive is FFS. It could potentially be used by MAC for activating reception of the 
physical chanel that carries DSCH if MAC signalling is used forDSCH resource allocation, i.e. in 
the case of MAC signalling on a DSCH control channel (c.f Case B in S2. 01). Will there be 
additional use for it in the TDD mode? 

The PHY-CONNECT primitives are used to request activation of the physical layer connection or to 
confirm that the physical layer connection has been activated. 

Primitives: request, confirm. 

Request parameters: 

• FFS 
Confirm parameters: 

• FFS 



8.1.2 PHY-DISCONNECT 

Note: This primitive is FFS. It could potentially be used by MAC for de-activating reception of the 
physical chanel that carries DSCH if MAC signalling is used forDSCH resource allocation, i.e. in 
the case of MAC signalling on a DSCH control channel (c.f. Case B in S2. 01). Will there be 
additional use for it in the TDD mode? 

The PHY-DISCONNECT primitives are used to request deactivation of the physical layer 
connection or to indicate that the physical layer connection has been deactivated. 

Primitives: request, indication (FFS) 

Request parameters: 
• FFS 
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Indication Parameters 

• FFS 

8.1.3 PHY-DATA 

The PHY-DATA primitives are used to request and indicate SDUs used for Layer 2 peer to peer 
communications passed to and from the physical layer. One PHY-DATA primitive is submitted 
every Transmission Time Interval for each Transport Channel. 

Primitives: request, indication. 
Parameters: 

• TF1 

• Type of slotted mode (e.g. no slotting, slotting of beginning/middle/end of frame) 

• Transport Block Set 

• CRC check result (indication only) 

• FFS 

8.1.4 PHY-STATUS 

The PHY-STATUS primitive can be used by the layer 1 to notify higher layers of an event which 
has occurred. 

Primitives: indication 
Parameters 

• Event value 

1 . Maximum transmission power has been reached 

• Transmission power 

1 . Allowable transmission power has been reached 

2. Average transmission power is below allowable transmission power 



8.2 Generic names of primitives between layers 1 and 3 

8.2.1 STATUS PRIMITIVES 

8.2.1.1 CPHY-Sync 

This primitive is used for LI to indicate to RRC that synchronisation of a certain physical channel 
has been done in the receiver. 

Primitives: 

CPHY-Sync-IND 

Parameters: 
FFS 

8.2.1.2 CPHY-Out-of-Sync 

Primitive sent from LI to RRC indicating that synchronisation of a previously configured 
connection has been lost in the receiver. 
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Primitives: 

CPHY-Out-of-Sync-IND 
Parameters: 

FFS 

8.2.1.3 CPHY-Measurement 

The Request primitive is used for RRC to configure LI measurements. The Indication primitive is 
used to report the measurement result from LI to RRC. 
Primitives: 

CPHY-Measurement-REQ 

CPHY-Measurement-IND 

[Note: The need for a CPHY-Measurement CNF is FFS. J 
Parameters: 

Transmission quality parameters 

FFS 

8.2.1.4 CPHY-ERROR 

The CPHY-ERROR primitive is used to indicate to the management entity that an error has 
occurred as a result of a physical layer fault. 

Primitives: indication 

Indication Parameters 

• Error Code 

8.2.2 CONTROL PRIMITIVES 

8.2.2.1 CPHY-TrCH-Config 

This primitive is used for setting up and configuring a transport channel, and also to modify an 
existing transport channel. 
Primitives: 

CPHY-TrCH-Config-REQ 
CPHY-TrCH-Config-CNF 
Parameters: 
FFS 

8.2.2.2 CPHY-TrCH-Release 

This primitive is used for releasing a transport channel. 
Primitives: 

CPHY-TrCH-Release-REQ 
CPHY-TrCH-Release-CNF 
Parameters: 
FFS 
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8.2.2.3 CPHY-Setup 

The Request primitive is sent from RRC to LI for establishment of a Radio link to a certain UE. 
The Confirm primitive is returned from LI to RRC when the Radio link is established. In case LI is 
unable to execute the request, this is indicated in the confirm primitive. 
Primitives: 

CPHY-Setup-REQ 
CPHY-Setup-CNF 
Parameters: 

Physical channel description 

8.2.2.4 CPHY-Release 

The Request primitive is sent from RRC to LI for release of a Radio link to a certain UE. The 
Confirm primitive is returned from LI to RRC when the radio link is released. 
Primitives: 

CPHY-Release-REQ 
CPHY-Release-CNF 
Parameters: 
FFS 

8.2.2.5 CPHY-Modify 

The Request primitive is sent from RRC to LI for modification of a Radio link to a certain UE, The 
Confirm primitive is returned from LI to RRC when the radio link is modified. In case LI is unable 
to execute the request, this is indicated in the confirm primitive. 
Primitives: 

CPHY-Modify-REQ 
CPHY-Modify-CNF 
Parameters: 



Physical channel description 

8.3 Parameter definition 

8.3.1 Received transmission quality parameters 





Request 


Indication 


Radio link list 






SIR threshold 






FER threshold 






SIR measured 






FER measured 







8.3.2 Radio link to be reported 

8.3.3 Error code 

ffs 

8.3.4 Physical channel description 



Primary 


Secondar 


Primary 


Secondar 


PRACH 


DPCH 


SCH 


ySCH 


CCPCH 


y CCPCH 
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Radio frequency 


■ 










- 


Primary Synchronisation code 


■ 












Secondary Synchronisation 
code 




- 










oCraluDling CUUc 




























Available Access slot 














Transmission Power level 














Preamble signature 














Frame Offset 















8.3.5 Action 





Primary 
SCH 


Secondar 
ySCH 


Primary 
CCPCH 


Secondar 
y CCPCH 


PRACH 


DPCH 


Activate Radio link 














Deactivate Radio link 















9 Radio Frame transmission 

9.1 Downlink Frame format 

9.2 Uplink Frame format 

9.3 Order of bit transmission 
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Annex A: Example of table that describes a Transport Format Set 

The following table describes the characterisation of a Transport Format Set. The possible values 
for the attributes will be defined by the LI experts group based on the requirements identified by the 
L23 experts group. Note that the allowed Transport Format Combinations are not described here, 
and will need to be covered also. 







Attribute values 


Dynamic part 


Transport Block Size 


list of values 




Transport Block Set Size 


list of values 




Transmission Time Interval 
(option for TDD only) 


list of values 


Semi-static part 


Transmission Time Interval 

(FDD, option for TDD NRT bearers) 


Value 




Type of channel coding 


Value 




Outer coding 


Value 




Outer interleaving 


Value 




Inner coding 


Value 




Inner interleaving 


Value 




Rate matching 


Value 
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